Security is a vital concern in the design and operation of computer systems. One important aspect of computer system security lies in software that assures that actions such as accessing data resources are only performed by the specific users who are intended to be authorized to perform the actions.
FIG. 1 depicts a model of how user authorization software may operate in some systems.
In FIG. 1, block 100 represents a computer system, including hardware and software (the hardware and software are not separately shown, except that some functional aspects of the software are represented by blocks presented within block 100). A human administrator of the system 100 is represented at 102, and a particular user (u) of the system is represented at 104. When the user u 104 wishes to perform an action a (e.g., accessing his/her electronic mail mailbox), he/she provides input 106 to the system 100 to request execution of the action. An authentication guard software module 108 may be provided to authenticate the identity of user u 104. For example, the authentication guard software module may require the user u 104 to complete a password-protected log-on procedure.
Once the authentication guard software module 108 has authenticated the identity of user u 104, the request 106 is turned over to an authorization guard software module 110 for a determination as to whether the user u is authorized to have the requested action a performed. The authorization guard software module 110 may make the determination by referring to a grant relation Grant (reference numeral 112) that has previously been specified by the system administrator 102.
The grant relation Grant may be defined in accordance with the following semantic model.
The grant relation Grant may be a subspace of the space U×A, i.e.:Grant⊂U×A,
where:
U is a set of users of the computer system 100 (e.g., all authorized users); and
A is a set of actions that may be performed in the computer system 100 (e.g., the set of all actions for which execution is to be restricted).
If and only if a user uεU is in the grant relation with action aε A, i.e. (u,a)ε Grant, then user u is authorized to execute action a by the grant relation, otherwise user u is not authorized to execute action a.
In other words,                (u,a)ε Grantu is authorized for a.        
In many cases an action a is an access to a resource in the computer system, and accordingly the action may be represented by the resource itself. Correspondingly, access control may be specified by a grant relation between the set of users and a certain set of resources. In some descriptions, users and resources may be called subjects and objects.
The grant relation of a complex system may be composed of a number (potentially a large number) of orthogonal subrelations Granti, where each subrelation has the same user set U but orthogonal or disjunct sets of actions Ai. In such cases, each subrelation can be separately specified and treated individually, as indicated below:A=A1∪A2∪ . . . ∪An Granti⊂U×Ai Grant=Grant1∪Grant2∪ . . . ∪Grantn 
Often, the overall grant relation is composed of subrelations where each set Ai contains all actions of the same type, e.g. read accesses to all files existing in the system. As each action generally is an operation dealing with an object that is part of the system, each set Ai can also be identified by the set of all existing objects of a certain type, e.g. all the existing files. Such subrelations may be referred to as atomic grant relations.
Since an overall grant relation is uniquely identified by its subrelations, for simplicity of explanation it may be assumed in some cases that Grant is atomic so that the set of actions A only contains actions of the same type. In such a case, set A may have a bijectively associated set of objects that the actions operate on.
Referring again to FIG. 1, the authorization guard 110 checks to see whether (u,a)ε Grant, and if so authorizes the user u to execute the action a, which is represented at 114 in FIG. 1. As noted above, the action a may correspond to an object such as a file for which the user u has requested access.
FIG. 2 schematically illustrates an example of Grant. In FIG. 2, the rounded-corner rectangle 202 represents set U of users, and each small circle within 202 represents a user uiε U. The rounded-corner rectangle 204 represents set A of actions, and each small circle within 204 represents an action aiε A. The lines 206 between 202 and 204 represent pairs (ui, ai)ε Grant. Thus, in the illustrated example, (u′,a′)ε Grant (user u′ is authorized to perform action a′), but (u′,a″)∉Grant (user u′ is not authorized to perform action a″).
In practice, a grant relation Grant⊂U×A may be specified by the system administrator in two alternative ways: by user permissions or by access control lists (ACLs). Such approaches may be more practical than, say, enumerating all tuples (u,a) belonging to the grant relation.
User permissions assign to each user the set of the user's authorized actions. User permissions may be modeled by a specification function perm with the functional signatureperm: U→P(A),
where P(A) denotes the power set of A.
The set perm(u) may be referred to as the permission set of u.
Assuming that only permission sets are used to specify Grant, then the specification function perm induces Grant, which is also written as [[perm]], the semantics of perm as follows:[[perm]]=Grant, with aεperm(u)(u,a)ε[[perm]]  (1)
Actions may be assigned to permission sets indirectly. For example, a role may be assigned to a user, with one or more allowed actions contained within the assigned role. In any case, user permissions may be semantically modeled by assigning actions to users in the course of a user administration function.
Referring again to FIG. 2, the dashed line oval 208 represents the subset of A which is the permission set of user u (perm(u)), which contains exactly the actions that have been authorized to user u.
ACLs operate in the opposite direction of the grant relation as compared to user permissions. ACLs assign to each action the set of users authorized to execute the action. ACLs may be modeled by a specification function ac with the functional signatureacl: A→P(U)
The set acl(a) may be referred to as the access control list of a.
Assuming that only ACLs are used to specify Grant, then the specification function ad induces Grant, which is also written as [[acl]], the semantics of acl as follows:[[acl]]=Grant, with uεacl(a)(u,a)ε[[acl]]  (2)
As with assignment of actions to permission sets, assignment of users to ACLs may be done indirectly. For example, a user group may be assigned to an action (or, e.g., to access the object that corresponds to the action), thereby granting permission to execute the action to each user that is a member of the user group. In any case, ACLs may be semantically modeled by assigning users to actions or to objects that correspond to the actions.
User permissions and ACLs directly model the grant relation. The grant relation can be immediately specified by the specification functions perm and acl, as indicated by the definitions set forth above. Thus perm or acl, as the case may be, positively specifies the grant relation, which may be a relatively intuitive way of specifying the grant relation, as contrasted with a negative specification of the grant relation based on grant restrictions. Another advantage of the positive specification of the grant relation via perm or acl, is that this approach may comport with greater security, since no action is allowed at the outset. Rather, particular grants of authorization are added one after another in the course of specifying the grant relation so that the basically restricted model is opened up step by step. In contrast, an approach for negatively specifying the grant relation entails an open model, in which every action is allowed in the absence of specification or when a generic construct like a wildcard is used; this may be considered less secure than the positive specification approach. However, the negative specification approach may be appropriate when most grants are not critical, but a certain limited number of grants need to be restricted/disallowed.
The discussion will now turn to the relationship of the specification functions perm and acl in the case where the same grant relation is to be specified. This relationship can be expressed logically as follows:[[perm]]=[[acl]]((u,a)ε[[perm]](u,a)ε[[acl]]
It follows from statements (1) and (2) above that[[perm]]=[[acl]](aεperm(u)uεacl(a))  (3)
This is as would be expected. Action a is effectively contained in the permission set of u if and only if u is effectively contained in the access control list of action a.
When implementing an authorization concept for an atomic grant relation, there are two main issues to consider, namely (a) what tool is to be used to specify the grant relation and (b) how the authorization check is to be performed by the authorization guard. As has been indicated above, user permissions and ACLs for atomic grant relations are semantically equivalent specification approaches. Thus either one can be used in practical implementations.
ACLs require that the actions in question be assigned to a set of predefined objects with predefined operations. These objects may be at different levels of abstraction, where a corresponding program or system has defined the access to the objects. Examples of such objects are files of an operating system or URLs (universal resource locators) for which access is defined by a web server.
In contrast, user permissions rely on the existence of a user administration system which typically is present in a non-trivial computer system. The user administration system may be available in the operating system or in the platform itself.
ACLs are typically stored together with other properties of an object to which the action a corresponds. User authorization in the case of ACLs may be checked at runtime by searching for the requesting user u in acl(a) whenever u requests execution of action a.
Correspondingly, permission lists are typically stored in the system's user administration facility. User authorization in the case of user permissions may be checked at runtime by searching for action a in perm(u) whenever u requests execution of action a.
Since both user permissions and ACLs are semantically equivalent, it is conventionally the case that the two are not used in parallel for the same atomic grant relation. To do so would require redundant storage of the grants and would entail synchronization of the user permissions and the ACLs, as implied by statement (3) above. That is, if both user permissions and ACLs were used in parallel, whenever action a is added to or deleted from perm(u) in the user administration facility, the corresponding action would have to be taken with respect to u vis a vis acl(a) in the assigned object administration facility for action a. The user administration facility and the object storage facility are typically accessed with different tools, so that parallel usage of user permissions and ACLs would require additional effort without any improvement in functionality. To the contrary, the usage of both specification approaches in parallel would provide additional targets for would-be attackers, and thus would tend to decrease the security of the grant relation.
In a typical computer system of any size the complete grant relation may consist of a considerable number of atomic grant relations. Since one dimension of each atomic grant relation is always the set of users, and since user administration is generally available within such a computer system, it is common to use user permissions to define the atomic grant relations. This may be advantageous in that it reuses the user administration facility.
In some computer systems, user permissions may be used to specify some atomic grant relations, and ACLs may be used to specify other atomic grant relations. For example, roles may be assigned to users, where the roles incorporate permissions across a variety of different types of actions. Flexible permissions may be implemented with use of wildcards or the like in the specification of the authorized actions.
However, for a subset of atomic grant relations, ACLs may be used in parallel with general user permissions. One advantage of supplementing general user permissions with ACLs is that the ACLs may be more intuitive and may be focused on only one particular atomic grant relation with a particular kind of objects. For example, the objects may belong to the domain of a particular application program, with each object denoting an individual entity. In such cases it may not be practical to assign authorizations for the objects with user roles, since the grants of authorizations for the objects must be specified object by object. Use of ACLs in these cases may provide enhanced security, because the ACL for a new object is typically empty, and the possibility of incorrect authorizations for the new object is reduced or eliminated. Also the objects and their actions are likely to be well-understood so that the model for authorizing access to the object also is likely to be well-understood.
However, the above described grant relation semantic system may not be very well suited to a situation in which it becomes necessary to supplement an implicitly established open authorization system (in which virtually all actions are permitted) with addition of one or more new sets of actions for which explicit restrictions/permissions may be needed.